When I was traveling a while back, I grabbed a small white metal tube out of my toiletry bag. Opened it up and then squeezed a small amount of this white cream on my toothbrush. A few seconds later my power toothbrush was whirring along and I had a thought. “This isn’t as foamy as I expected. Did I not put enough toothpaste on my brush?” The lack of a minty taste should have said something, but let me say one thing here:

This story is 100% true.

So, still completely sure it was the toothpaste’s fault, I put more on the brush, as one does. Then I try again. Still not doing what I had hoped. At this point, because I am not completely stupid (and my mouth was starting to feel funny), I realized…know what? This may not be toothpaste, and it wasn’t. Maybe don’t try this again. 

But why did I do this? Pure muscle memory. That tube of face cream looked so similar to my toothpaste that I just grabbed it without thinking and kept going about my business. 

Of course this is not about dental hygiene

Glossing over my borderline dangerous real world organization skills (I wish this was first time I have made a stupid mistake with my travel bags), this problem of muscle memory pertains to the process of creating things like software and devices as well. In this case I don’t want to focus on the actual code you write, but rather the interface that that code creates. There are two high level times when this comes into play. Changing interfaces, and creating new ones. 

As a (hopefully) more relatable example, have you ever tried to use a keyboard that you aren’t used to? When I work in our Cambridge office, they have UK keyboards. UK keyboards have mostly the same key patterns, but are slightly different for a few key placements. The same happens when I am working from my iPad keyboard. The letters are in the same location, and I can adjust to the key size okay, but when I need a key that isn’t in the exact same place, I tend to hit it instinctively, and then have to try again.

Changes in and of them selves aren’t bad

Changes to a user interface, sometimes to update an interface for modernization reasons, is a noble goal. Who wants their software to look like it was created in 1993 using Visual Basic 1.0? However, if you have a loyal user base (often people who work with you,) those changes need to be done carefully. 

Changes in a software interface are a very common source of errors. In this article , Page Laubhrimer discusses a memory model that the user of an application makes. For example, who doesn’t have an app where you know where to click and do it without thinking or reading the dialogs that come up. 

As such, we are all an aware of some interface you once used regularly that underwent a complete change that initially made you angry. For example, if you are an iOS user who takes any number of pictures, you may recall when iOS 18 came out and they had overhauled the entire photo interface. 

Nothing was where it was expected, and of course everyone hated it. Certainly some very vocal users did. I wasn’t immediately a fan either. Yet, now after some time and practice, I have warmed to the changes as I got used to them. In fact, I have warmed to a lot of these changes at this point. So, I am not here to tell you to never change your patterns, just to remind you that you need to manage that change and ease people into it.

Patterns matter as well

However, large changes aren’t the biggest problem for muscle memory. Large changes are frustrating, but far easier to change into. It is the subtle ones, typically where you may not immediately notice a difference. For example, say you buy a new car, and due to some research, it was decided that swapping the accelerator and the brake pedals would make travel safer. You can imagine what would initially occur. People would forget which pedal was which and best case, crunching metal and plastic would occur. It would require a lot of muscle memory training to make such a leap. Eventually that desired increase in safety might happen, but the cost initially might be huge.

Subtle changes occur all the time in software. Like if you have a few buttons on the screen. If you go from [cancel] [ok] to [ok][cancel], or something like [save][delete][cancel], people will make mistakes just positionally as they click where the button they wanted used to be as they wail: “It was always like this, why did they change?!?” This becomes especially true when you have users who use hotkeys and they barely use the user interface.

It doesn’t even need to be the same software that is involved either. Using SSMS for SQL Server, ADS (Azure Data Studio, depreciated), and DBeaver to execute queries, there are a set of keys that you can use to execute queries. F5, Ctrl-E, and Crtl-Enter, and it never fails that I try the wrong one. And SSMS has Ctrl-R to remove the results pane that I try in almost every tool that I miss when using many many software packages!

What about internals like database design?

While this concern about user interfaces is perhaps obvious, the same goes true for designing a database, or a PowerShell cmdlet, a function, a CLI (command line interface) or any bit of reusable software. The users of your software are apt to make mistakes if you aren’t careful and warn them as much as possible. 

A common example in database design is naming a surrogate key for a database. If you have a table of customers, users of that structure ought to be able to predict the name of the surrogate primary key. There should be a customerId, customer_id, custId (if your platform doesn’t allow long enough names and you are forced to abbreviate), or something similar. If you can predict the name of the customer table surrogate just by knowing a little bit about the database, they you can also predict all the other ones too.

Customer is to customerId as Product is to ________.

And if that answer isn’t productId, then you have an issue. 

In all things you design, following a common pattern is essential to the sanity of your users. Creativity is a great thing, but some things have to follow a standard. And if you are changing an application, even for the better, you need to make the path smooth for the user so they don’t do something stupid because of muscle memory. 

Conclusion

Sadly my organization/normalization skills with data don’t translate that well to the physical world (I can’t build a uniqueness constraint on my bag that doesn’t allow two small tubes of similar size and shape to be put in my bag. And despite failure being a great teacher, sometimes that lesson is “I should stop using software made by this person or company.” And, if you aren’t careful, that lesson is going to be the start of a different lesson in finding a different line of work.